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Page 15, line 44, before "Appendix" please insert -Microfiche--. 
On page 30, line 4, before "What is claimed is:" begin a new paragraph and insert the 
following (from page 7, lines 26-28 and Appendix C filed with the application; no new matter is 
being added): ^ 



? 



^N^* ^The following description contains excerpts from/amanualyflescribing one 
implementation of the electronic commerce system outlinecl^above^ 

Transact Architecture 
Why Redesign the Architecture? 
Transact 4 is conceived as the Transact release that: 
° Provides a product with a complete set of features 
° Exposes many internal layers to customization 
° Allows customers to write applications 

Transact 4 sets the standard that all similar Internet/commerce products must meet 
because of this unique combination of inside-out exposure through the rich feature set and 
outside-in access through customization and the APIs. There are other commerce products that 
claim to provide similar ability to customize or extendyfeatures. The other products suffer in 
comparison to Transact 4 because they provide shell ^PIs with no built-in functionality. It is as 
though the programmers wrote an operating system API without implementing file systems, 
memory management, and other expected features of an operating system. Instead, the product 
designers expect the software owner to provide the(e features. Transact 4 achieves the difficult 
task of providing a fully functional Internet commerce operating system with all the hooks 
necessary to extend or replace core components^/ 

Many owners will be satisfied using Transact as it is after installation, without any further 
customization than editing the screens with their favorite HTML editing tool. Sellers and their 
employees, especially, will appreciate the Commerce Center that gives them access to store 
registration and management. Access to core business logic in the product through APIs allows 
customers to write modules to extend prodt/ct functionality without requiring recompilation, 




matter is a 



relinkage, or reinstallation of the product 

Examples of customization in Transact 4 are: 
° Sellers and administrators can customize large portions of the user interface. 
° Sellers and administrators can legalize the product to the language of their choice, 
including those with multibyte character encoding. 
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0 Sellers have a wide variety of payment options they can choose from in Transact. 

0 Core objects in the system can be tagged with extra or custom fields defined by the seller. 

The fields are retained in the system and are retrievable /ia the user interface and the 

APIs. 

Examples of APIs available for customer applications/ are: 
° The Buyer Profile API, designed for customers who/vish to load the transaction database 

with existing customer information that they already have. 
° The Fulfillment API, which stores the purchase history and provides the mechanism 

necessary for writing custom fulfillment applications. 
° The Microtransactions API, which lets customers write their own prepay or postpay 

microtransaction applications with their own user interface. An owner can replace or 

extend any aspect of microtransaction functionality without affecting the core product. 
° The Order Entry API, which lets customers Implement their own catalog or shopping cart 

applications that deposit orders into Transact, bypassing the Transact buyer user 

interface. 

Examples of extensible and replaceable yhodules in Transact 4 are: 
° Payment modules - These modules are for enabling both payment brands, such as Visa, 

and payment agents, such as First USA Paymentech. 
° Order Entry modules - These modules plug in to the order capture subsystem of Transact 

4 that performs activities like inventory checks or payment card fraud checks. 
° E-mail modules - Owners can replace the way Transact 4 sends e-mail to users, including 

the encryption method. / 
° Fax modules - Owners can replace the way Transact 4 sends faxes. 
° Smart Pages modules - Owners who want to customize screens for each buyer can write a 

module to do this. / 
° Tax modules - Owners can replace or extend the way Transact computes sales tax. 
The Payment API is a public API. ^41 the other APIs are leveraged with the help of Open 
Market consulting services. 

Foundations 

Transact 4 is a collection of objects, components that contain those objects, and 
applications that use the component and object APIs. There are no monolithic applications in 
Transact 4, instead, all Transact applications, such as all the buyer CGI scripts, are clients of 
component APIs. It is therefore psy to discuss scenarios where components may be replaced or 
extended without requiring changes to the basic applications. 
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Component Architecture 

The component architecture of Transact 4 leverages the ideas and technology behind the 
Microsoft component object model (COM). COM describes a world where components define 
classes and classes implement interfaces. Interfaces are the common lingua franca; components 
and classes may be replaced, extended or revised without requiring client changes as long as they 
continue to implement the same set of interfaces. 



The strength of COM is that it provides a meohanism for independently written software 
components to find each other through the registry, launch each other through dynamic linking, 
and a common language through their interfaces. 

For example, someone wishing to write a new kind of payment instrument in Transact 4 
does so by implementing a new component/ assigning it a new class identifier, and ensuring that 
the component implements the appropriate /payment authorization and settlement interfaces. The 
component is physically a shared library tnat can be dynamically linked into Transact 
applications. Transact 4 provides a registw where information is stored about the new 
component, such as its class ID, where it lives, and which interfaces it support. The next time a 
Transact application that needs available payment options is launched, it interrogates the registry 
to find the new component. / 

Transact 4 ships with some components, for example, e-mail and fax. Information about 
these components can be found in the registry as well. They are implemented as dynamically 
linked libraries with class identifiers and other necessary COM information. The effort required 
to replace or extend them is similar to the effort required to develop a new payment component. 

Architectural Overview / 

Transact is an order capture and processing system that interacts with one or more 
payment modules that handle the payment for orders. In addition to handling orders, it provides 
features for sellers to manage their stores, an interface for buyers to complete and monitor 
purchases, and tools for an administrator to monitor Transact. All of the Transact subsystems 
operate with a common set of business objects: 

Order object. This object represents a contract between the buyer and seller. The object 
captures all information relevant to' the order, including the items being ordered, the terms and 
conditions, the payment information, and the fulfillment information. The moment of capture 
occurs when the buyer clicks a "buy" button; until that moment the order information is stored in 
a shopping cart. 



Applicant 
Serial No. 
Filed 
Page 



Brian J. Reistad et ai. Attorney's Docket No.: 06543-035001 

09/054,180 
April 1, 1998 
5 



Invoice object. This object represents a fulfillment yevent, where goods or services are 
delivered, fully or partially, to the buyer. Any subset of goods or services in an order can be 
shipped, canceled, returned, or charged back. One invoice object represents one action to one or 
more items in an order object. 

Principal object. A principal is an entity that cAn be authenticated. This object identifies 
the software component or person contacting Transaot, so Transact can ascertain who the entity 
is and what it is allowed to do. 

Payment instruction. The pmt Instruction object captures information concerning the 
mechanism for funds transfer between buyer and seller, such as a payment brand, authorization, 
or a payment agent. 

The user interface and application logic afe interfaces to users. There is a library of 
common user interface screen components, for example,*the order form or the name address 
block, that are shared among subsystems. / 



There are three groups of applications: 
Buyer applications. This group implements all buyer activities, including order capture, 
order status, payment account establishment/payment account updates, Smart Statements, and so 
on. j 

Seller applications. This group implements all online business activities, such as 



managing the store, presenting statements^/processing orders, and generating reports. 

Administrator tools. This group implements Transact administrator activities, such as 
configuration, key management, and maintenance. 

The user interfaces for these applications depends on a common set of libraries: 
Smart Pages. This library provides a common set of HTML screen components, such as 
a name address block for rendering addresses. These are the screen components that provide a 
template mechanism for rendering HTML screens. 

HTML/HTTP common services . These libraries provide a common set of server-side 
HTTP protocol and HTML services for handling requests, parsing query strings and form POST 
data, handling URLs, and so on. / 

The core subsystems provide the base functionality on which the buyer, seller, and 
administrator applications are built/ The core subsystems implement the functionality behind the 
Transact APIs. 

They include: 

Order-invoice subsystem. /This subsystem provides services that accept and validate new 
orders, as well as update and report on the current state of orders and invoices in the system. 
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Store subsystem. This subsystem maintains me status of the business and provides a set 
of seller services related to order processing, including tax and shipping calculations. 

Directory subsystem. This subsystem maintains a database of all Transact users, known 
as principals, and of all addresses when principals pave addresses. For example, a buyer is a 
principal with associated addresses. A fulfillment/ module is a "user" of the system, but it has no 
address. This subsystem also provides a set of services for adding, deleting, retrieving, and 
authenticating users. 

Payment subsystem. This subsystem prdvides payment services, such as authorization 
and settlement. The payment subsystem hides most of the details of particular payment 
instruments, so new instruments can be added pere with minimal or no changes to other 
subsystems. 

Logging subsystem. This subsystem provides a central event logging facility for all other 
subsystems. 

All subsystems depend on a set of co/nmon utility libraries for string handling, message 
catalogs, hash functions, and so on. All subsystems gather configuration information from a 
common facility called registry.asc. 

Core Business Objects 

This section details the core objects/ that are sued by nearly all subsystems. 
The business objects mentioned at me beginning of this chapter are just portable data 
tructures that represent the contents of business documents such as orders, invoices, and 
receipts. They are not backed by a database, though they are certainly stored in databases, and 
can be carried anywhere a byte stream can be handled, for example, MIME attachments in e- 
mail, HTTP, flat files, and so on. Examines of these objects are the order, orderltem, invoice, 
invoiceltem, and address objects. 

Transact subsystems provide service objects. Service objects accept, process, and find 
business objects such as orders, invoice; , payments, and addresses. Each of the business objects 
implements the following methods: 

Mutators. These methods are us ed to change or set object state. The methods may 
perform basic error checking such as st ing length checking, or they may prevent updates for 
objects in a read-only state. 

Accessors. These methods reac 



Serialization and deserialization 



or get object states. 

. These methods write and read the object contents to a 
byte stream. The stream is portable; objects serialized on one platform are readable on all other 
platforms. The stream is reasonably compact, as the pbjects have to be passed over slow dial-up 
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links, for example, for the order capture subsys tern. The stream may contain various consistency 
checks, such as a unique type identifier and a checksum. The stream representation has a version 
number, so that objects can be revised, yet be backwards compatible to old streams. 

The serialization and deserialization methods are inspired by the Microsoft structured 
storage for persistent COM objects, though oui approach is restricted to simple byte streams. 

The service and business objects do noi have any user interface components. The 
presentation of the data contained within the objects is handled by Smart Pages. 

All strings in all objects support the Unicode standard for encoding characters. For 
places where strings show up in external interfaces, the UTF-8 variable length encoding, which 
is backward compatible with 7-bit ASCII, is preferred 

Order and Orderltem Objects 



An order object represents the contract 



between buyer and seller for the items ordered 



and the terms and conditions of the sale. An orderltem object represents a line item in an order. 
The order object contains zero or more orderltem objects. 

Open Market made some simplifying design assumptions for the order object: 
° Each order has a single billing addressj and a single shipping address. If you want to ship 

different items to different addresses, j;reate multiple orders per destination address. 
° Each order is for items from a single store or business. If a buyer wants to buy items 

from multiple stores, then he or she creates multiple orders. 

Note: The above assumptions about (the objects do not prevent us from implementing a 

multiple-address, multiple-store user interface for buyers. 
Current order status is maintained byjthe order-invoice subsystem. That subsystem 
provides services for looking up existing orders, adding new orders, and changing order status. 
Invoice and Invoiceltem Objects 

An invoice object is a record of fulfillment that is created every time a shipment or 
cancellation occurs. j - * : 

An invoiceltem is one of the items in the invoice that was shipped or canceled. We make 
the simplifying assumption that every invo ijee refers to only one order. An order can have 
multiple invoices associated with it, one for each fulfillment activity related to the order. An 
invoice has a single billing and shipping address. An invoice also has a single pmtlnstruction 
object associated with it. 

Payment Instruction Object 

A pmtlnstruction object is created when the user submits an order form. It encapsulates 
the payment contact between the buyer an4 seller, the payment obligation of the buyer, the 



Applicant 
Serial No. 
Filed 
Page 



Brian J. Reistad et al. 
09/054,180 
April 1, 1998 



Attorney's Docket No.: 06543-035001 



payment instrument that the buyer wants to use and the seller agrees to accept, as well as the 
state of funds transfer between the buyer and seller. 

A Transact payment agent modi le uses methods to accomplish a payment authorization 
and funds transfer. The payment object carries the payment brand identifier of the payment 
module. 

Address Object 

The address object is used to ho d postal address, e-mail address, and other contact 
information. The address object is contained within other objects, such as the order and invoice 
objects. 

Applications 

This section provides further in: brmation about the Transact application software. It is 
divided according to user class, however, many applications are used by a combination of user 
classes with different information avail ible to different classes. 

Buyer Applications 

The buyer applications group together user interface, API, and functional logic for buyer 
tasks into CGI scripts. Four of the major applications are described below. Other buyer 
applications include: 

0 payinfo.cgi - allows buyers to n gister payment cards 
° subsummary.cgi - view of subsc ription history 
° microbuy.cgi - features for making microtransactions 
° microbal.cgi - view of current prepay balance for microtransactions 
Order Form Application 

The order- form. cgi script provides the user interface and application logic for composing 
and capturing orders from the buyer. 1 he output of the order capture process is a complete 
order, which is handed off to the order invoice subsystem for processing. This module provides 
an API that supports the implementatic n of ActiveX and Java user interfaces for order capture. 
It can also support the implementation of remote" user interfaces, where the interface runs on the 
content server, but uses order capture s ervices provided by Transact. 

This module implements an H r 'ML user interface on top of the Order Entry API. This 
user interface implements an HTML v srsion of everything needed to capture an order: 
processing incoming digital offers (DOs), maintaining shopping carts, and collecting payment 
information. This user interface is commonly referred to as the buyer flow, and represents most 
of the functionality in the payment.cgi script that was in Transact 3.0. 
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Modularizing order capture generates implementation flexibility. In the future, it allows 
for specialized order capture modules for particular applications. These variants can run 
simultaneously on a single Transact server, each sharing the common core for order processing 
and service. Example modules include a: 
° Specialized retail module 
0 Business-to-business module 
° Buyer work flow order approval module 
° Support for negotiated prices module 

Statements and Receipts Application 



The smart-statement.cgi and smart-re xipt.cgi applications provides a user interface and 
application logic for servicing the buyer's onjer after it has been captured. Order service tasks 
include: 

° Displaying the Smart Statement 
° Processing order and invoice status 
° Handling payment failures 
° Making returns and credits 
User Information Module 

The user information module implements a user interface for buyers to perform 
registration maintenance tasks through userinfo.cgi, including: 
° Registering for the first time 
0 Changing registration information 

Seller Applications 

Seller applications implement the user interface and application logic for sellers to 
register and manage their stores. The Commerce Center is run by indexxgi. Sellers use smart- 
receipt.cgi and smart-statement.cgi to monitor and fulfill orders. The reconcile.cgi script is used 
by both buyers and merchants to review anc solve payment card problems. There are four main 
groups of seller applications: 

Store Registration Module 

The applications store-registration.cgi, oaa_select_tax.cgi, oaa_vat_register, and 
transport.cgi let sellers create stores and specify various store parameters such as: 
° Store locale 
0 Store currency 

0 Acceptance of purchase orders or ftiicrotransactions 
0 Store payment agent parameters 
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° Shipping options 
0 Tax options 

The transport.^ script lets a seller designate a fulfillment party to perform shipping 
activities. This module\allows for partial shipment and cancellations and makes extensive use of 
the Transact Fulfillment WPL 

Reporting Module^ 

This module enabled a variety of seller reports, including the ability to define new 
reports. Examples of report\ are: 
° Customer listings 
° Orders placed at your Store 
° Payment details and processor information for reconciliation purposes 
° Tax reporting on the amibunt of tax charged on an order or invoice. 

Tax audit reports are still\downloaded directly from the transaction database. 

The supporting architecture for the reporting module is to extract a reporting database 
with a subset of information from me main database in the following way. 

Transact run jobs that put "slices" of the seller's data in Microsoft access format onto the 
Transact file system in a specific directory. These extracted files are encrypted because payment 
card numbers might be in the data stored. 

The remote client browses this directory to see which new files are present. The client 
then makes a secure request for the fil^s with the Transact reporting client. The reporting 
module authenticates the seller, validates the request, decrypts the files, and opens the files to 
download the data. 

Sellers retrieve the Access database and store it on their desktop. Reports can be 
generated on the data using any reporting tool that supports Access. 
Microtransactions Module 

The microtransactions subsystem Separates fulfillment and settlement by allowing 
authenticated buyers to either prepay or postpay for access to digital goods. 

It introduces the tab object, which keeps a tally of a buyer's charges and credits at one 
store. The microtransaction configuration object records settings for microtransactions for one 
store. The microtransactionltem object is analogous to an orderltem object, representing one 
purchase of one digital good. 

In both the prepay and postpay case, tfhe buyer chooses a digital good marked as a 
microtransaction. The microbuy.cgi script processes the offer by debiting the buyer's tab, then 
redirecting the buyer to the digital receipt, creating an effect of going directly to the information. 
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For postpay accounts, there is an additional step, performed through the Micro transactions API, 
that aggregates the microtransaction pure! ases into an order. The order is then passed to the 
order-invoice subsystem for processing. 

When a buyer establishes a prepay tab, the amount is authorized and settled before 
delivery of the goods occurs. When a buy<r is approved offline for a postpay account, the buyer 
delivery occurs before payment is completed. 

Taxes are calculated on the entire p epay amount before it is authorized, so taxes are 
included in the authorized amount. In the p ostpay case, taxes are applied to each digital good, 
then the total for that item is added to the ta b. 

A second script, microbal.cgi, allows buyers and merchants to review the buyer's tab. 

Subscription Module 

Sellers and buyers also use the scripts concerned with subscriptions, which allow for 
purchasing and accessing online content over an unlimited or a specified length of time. The 
subscriptions component takes the order from the order capture subsystem before the moment of 
capture. It analyzes the digital offers an enters data into the periodical, subscription, installment, 
and installment_plan database tables. Invoices, created by an ongoing job run by Transact, 
trigger payment at the appropriate intervals. 

Subscription applications include: 
° authorize.cgi - This application, used for many reasons within Transact, allows users 

access to Transact scripts and content. A buyer only needs to log in or register 

themselves once before viewing content. 
° subscription.cgi - The subscription application verifies that the buyer has paid for a 

subscription. It then authorizes theijn to access content areas they have paid for. 
0 subsummary.cgi - Buyers can review subscriptions they have purchased. 
0 sub-manage.cgi - Sellers can manage prices or cancellations of subscriptions. 
° sub-acl.cgi - Sellers use this application to mange access control lists (ACL) to 

subscriptions. 

Administrator Applications 

Administrator tools provide the user interface, external interfaces, and application logic 
for Transact administrators to run their system. There are three modules. 
Installation Module 

This module is structured so that all queries of the installer are made before the actual 
install. The install module decompresses ail the servers through untar and places them 
appropriately on the host machines. 
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Upgrade Module 

After an installation is complete, the upgrade module can be invoked to copy all relevant 
data from an existing Transact 3.0 system to the new installation. This data includes: 
° The transaction database 
° Payment processor information 

0 Relevant Transact and satellite server configuration information 

0 Web server configuration information, including the migration from Open Market Secure 
Webserver to Netscape Enterprise Server 
Administration Module 

The third module is the forms-based administration screens and functionality. This 
module has not been extensively upgraded for Transact 4. Relevant applications include: 
° index.cgi - Presents thAmain FBA screen. 
0 configure-agents.cgi - Cbntrols configuration of payment agents. 
° acct-validate.cgi - This cmtical installation step is used to configure the payment 

processor that is used for address verifications (AVS). 
° payment-errors. cgi - Lists errors in payment card transactions. 
0 logmessage.cgi - Displays log messages in HTML format. 
° info-deliver.cgi - Presents tire administrator tools menu. 

Application Program Interfaces (APIs) 

The objects, applications, ana subsystems are connected through the use of APIs. Note 
that some of the APIs in the scheme Helow are internal: internal Payment, user service, and store 
service. Subscription authentication, settlement, and fax advice of orders are conducted with the 
help of HTTP. Descriptions of the AP|s from a designer's perspective can be found in "APIs" on 
page 69. \ 

Buyer Profile API \ 

The Buyer Profile API, formermcalled the customer database API, which enables bulk 
loading of buyer information from an exiernal database to the Transact database. This API is not 
enhanced in Transact 4. I 

Fulfillment API \ 

The Fulfillment API has two major purposes: 
° Order and invoice query \ 
0 Invoice creation and entry into the database 

Order and invoice query are used b>\ applications that wish to query the status of orders 
that match specific criteria such as: \ 
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0 Order number 
° Range of ord^r numbers 
° Date range 
° Buyer name orAaddress 

Invoices for retrieved orders can be queried as well. 

Transact buyer and seller applications make extensive use of the order and invoice query 
mechanisms in the Fulfillment API. 

Invoice creation amd entry are used by applications that wish to augment the shipping 
module, either by presenting bulk shipping functionality, or by custom shipping user interfaces. 
An invoice is created for e^ery shipping or cancellation activity, partial or full. An associated 
payment instruction object is created and funds transfer initiated, if Transact is expected to do 
settlement. The invoice is tlLn entered into the transaction diabase. 

Order Entry API \ \ 

This API is the heart oVthe order capture subsystem; it Is an API that separates the order 
capture function from the useAnterface. It also has the important property that it can work 



securely with nonsecure clients\ that is, it doesn't depend on an^ client to do the final 
calculations. 



\ 



The API uses an offer-counter-offer style. Clients create* order objects representing 
proposed orders, then the subsysl^m gets the order proposals, verifies them, and creates another 
order object representing the counter-offer, which also includes calculated values for tax, 
shipping, and discounts. The counter-offer order may include a set of restrictions from which the 
buyer has to select, such as a limited number of shippers, before the seller accepts the final order. 

The order entry API invokes the underlying services of stores, authentication, and 
payment as necessary to verify the carder contents, calculate various (Wived values, and accept a 
valid order for injection. Once a valid order is captured, it is handed o^f to the order injector for 
processing by the rest of the system. 
Payment API 

The Payment API has two parts, one that works internally with Transact, and one that 

\ 

allows system integrators or Open Market consulting to add new payment modules. 
Transact Internal Payment API ^ 

There is a large and complex part of payment internal to Transact. The internal Payment 
API is a collection of APIs to encapsulate those portions of Transact that know about the details 
of payment. 
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This internal API makefc it possible to create a payment instruction object and move it 
through the states of authorization and funds transfer. The information provides includes: 
0 Information about the buyer payment instrument 
0 Brand issuing the instrumdnt 
° Authentication method for the payment instrument 
° Payment agent and acquirers 
° Amount and currency of funas transfer 

External Payment API \ 

Open Market offers only a fraction of all the payment options possible with Transact. 



The external Payment API provides a\>et of modules that allow new forms of payment to be 
added to Transact without changes to the rest of the Transact installation. Transact payment 
modules may implement one or both o^the following objects: 

Payment brand. An entity that issues payment instruments and backs them, for example, 
Visa. A module that implements a particular payment brand may elect to use an existing 
payment agent for authorization and settlement. For example, a new Winnie-the-Pooh brand 
credit card may elect to use a First USA P*aymentech payment agent, because First USA can 
support the new card. 1 

Payment agent. An entity that can manage funds transfer between the buyer payment 
instrument and the seller, e.g., payment processors, a SET payment gateway, a Mondex value 

\ 

The module implements the authorization and settlement methods. Replaceable payment 
agents allow for a variety of payment mechanisms, each of which supports a radically different 



acquirer, or a billing system. 



paradigm for authorization and settlement. 

Security on the Internet is a concern fd^r many buyers and sellers. As a Transact owner, it 
is part of your role to reassure sellers and buyers about the relative safety of the Internet and the 
specific ways in which Transact protects them. ^The power of the World Wide Web and the 
Internet on which it rests does depend on its con^mon protocol and open architecture, but that 
doesn f t mean that Transact cannot protect the transmissions and data necessary to conduct 
business. This chapter looks at areas where security is a concern and the way Transact responds. 
Open Market has put a great deal of effort into successfully securing Web transactions, so that 
consumers and businesses can feel confident that abuses are averted. 

It's also important to encourage businesses ahd consumers worried about security issues 
on the Internet to make a realistic assessment of the tasks. For example, most visitors to a 
shopping mall don't think twice about giving their paVment card to a waiter or sales clerk, even 



